Since the beginning of digital computing, software security has been important to software vendors and users. Computers are commonly used to perform operations on sensitive data where the data itself and the computational instructions must be safe-guarded. Early computing devices operating on sensitive information were physically isolated, to protect the data. However, as computing devices became more pervasive and interconnected, the need for secure computing in non-secure locations by non-trusted users became necessary.
Effective software protection must address at least two threats to software applications: software integrity and confidentiality. Together, these comprise anti-tamper protections. Software integrity attacks try to modify program instructions. Maintaining software integrity ensures that secure software runs the way developers programmed it to. Software integrity also ensures that the user can trust that the program has not been altered beyond the developer's creation and that threats from viruses and malicious users that rely on code modification are minimized or eliminated. Secure architectures provide confidentiality; in contrast, trusted architectures generally do not. Software confidentiality offers protection from threats such as unauthorized or unlicensed copying of programs including piracy and the reverse engineering of algorithms. Software confidentiality is also employed to protect intellectual property and avoid unwanted disclosure to the public, competitors and/or potentially malicious entities. Likewise, these same principles of integrity and confidentiality also apply similarly to raw data that is stored, maintained or used by computer systems.
There is an increasing demand for software protection in modern computing systems. Contemporary software protection often requires maintaining confidentiality and integrity of software during distribution, in external memories, and during execution. Although various approaches attempt to provide both tamper resistance and confidentiality for software, these approaches typically assume that certain software operations will function, or they require fundamental changes to the way an operating system and applications interact. For example, the inherited trust model used by many conventional computing environment security systems is an unsatisfactory security solution. Indeed, if a trusted module is compromised, the rest of the system trusting that module can no longer guarantee protection. Such problems are further compounded by the lack of confidentiality. Other conventional computing environment security arrangements that rely less on trusted software components typically require fundamental changes to the way the application software operates and/or how the processor and operating system interact with the software. Such security arrangements may provide software protection, but due to the fundamental changes and incompatibilities with contemporary software models they are not easily incorporated into many computer systems.
FIG. 1 diagrammatically illustrates the problem of software vulnerabilities and threats that typically exist in a conventional unprotected computing environment. Several different types of attacks may be staged against an unprotected computing environment that can compromise the confidentiality and/or integrity of a user's software applications and/or data. For example, an attack on a user's proprietary software and/or data 10 might be perpetrated by a malicious software process 20 that is stored in an external unprotected memory. Alternatively, an attack might be also staged during the distribution of proprietary software/data or through execution of a physical access/invasion of an external memory bus or via the electrical connections on the processor itself.
Early secure coprocessor efforts, such as the IBM 4758, attempted to circumvent at least some of the technical challenges of secure computing by providing a protected compartment for sensitive data and calculations. Other types of security features used for software protection include stack protection, memory management unit modifications, memory integrity verification, and memory segmentation. Some parties have proposed even more subtle protection mechanisms such as flow control obfuscation, execution flow tracking, executable augmentation, and program shepherding. Most, if not all, of these approaches provide only limited protection against unauthorized execution and, moreover, fail to provide adequate privacy and protection against unauthorized access to the software or data. Moreover, a significant drawback with existing hardware-focused architectures is that they typically require substantial alteration of the host processor operating system or memory subsystem.
In addressing the many drawbacks and failings of the prior art approaches, the inventors developed a hardware-facilitated secure software execution environment (SSEE) method and apparatus which does not require substantially altering the user's host computing environment and which solves the problem of protecting the integrity and confidentiality of executable software and raw data during storage, distribution and/or execution. Effectively, the native CPU/processor hardware and memory systems protected by the SSEE may be treated as inalterable black boxes—requiring little or no change to the programs running on it. The hardware-based SSEE implementation disclosed herein provides privacy and anti-tamper protection for both proprietary software and raw data, and may be readily implemented within most networked and embedded computing systems. The illustrative example SSEE disclosed herein may also be implemented as an architectural augmentation for conventional microprocessors and conventional multiprocessing operating systems such as Linux.
The heart of the architecture of the SSEE is based upon two primary functional units: an encryption management unit (EMU) and a secure key management unit (SKU). In the disclosed non-limiting illustrative example implementation of the SSEE, the EMU is a hardware-based logic core that provides a ‘just-in-time-for-execution’ memory-page level decryption of encrypted executable instructions (or encrypted raw data) which may be obtained from a non-secure source (such as an unprotected memory device). A secure external key source communicates over a secure channel with the SKU. The SKU functions to supply and/or to build decryption keys for the EMU according to a predetermined key management scheme by using credentials stored on the secure external key source. The SKU combines the credentials in one of a variety of ways to create the keys for the EMU. This simplistic architectural arrangement of specific functional components within the SSEE provides a security framework that explicitly trusts only hardware while augmenting, rather than replacing, any existing process isolation mechanisms (such as memory management) that are controlled by the operating system.
In the non-limiting illustrative example implementation disclosed herein, a Harvard architecture CPU core is instantiated on the same silicon chip along with the encryption management unit (EMU) circuitry and the secure key management unit (SKU) circuitry. Specific credential information is acquired from one or more sources and combined by the SKU circuitry to select or generate one or more security (cryptographic) keys that are provided to the EMU for use in decrypting encrypted program instructions and/or data obtained from a non-secure off-chip memory device.
At least one beneficial aspect of the above architectural arrangement is that it readily enables use of various strong multi-key encryption schemes. For example, one possible multi-key management scheme might rely on multiple cryptographic keys and/or credential identifiers for accessing/creating a key which are provided to users by a software application developer or other distribution controlling authority. Each user then keeps their own personal cryptographic key or key credential identifiers stored on a separate individually assigned secure source device, such as a smart card, a flash dongle or a secure token. Alternatively, specific decryption keys and/or key credential identifiers may be provided by the software application itself or even from a specific instantiation of the processing system hardware or any combination of the above.
As also mentioned above, one aspect of the exemplary non-limiting illustrative implementation of the hardware-facilitated secure software execution environment and method described herein is the use of page-level encryption. Many, if not most, contemporary computing platforms/environments operate using at least some form of virtual paged memory. As is well known in the art, a virtual paged memory arrangement allows a program (or selected data) to be represented virtually within the physical system main memory space. A translation look-aside buffer (TLB) is conventionally used to provide the virtual-to-physical address mappings. Pages of the program (or data) may be easily mapped in and out of memory as necessary, with different pages from different programs populating the same physical memory space at different times. This arrangement, among other things, enables multiple programs to exist in main memory at the same time and also allows programs that are larger than the existing system memory to have a subset of pages loaded for execution. In the disclosed SSEE page-level encryption arrangement, each page in a computing system's non-secure physical main memory is associated with a specific key and possibly some additional ancillary data. The EMU decrypts a single memory page of encrypted instructions (or data) per single corresponding encryption key provided by the SKU. In this manner, different encryption keys may be used for different memory pages of the same program, strengthening encryption and preventing replay attacks between pages.
Another aspect of the SSEE is that, although instantiated on the same chip, the CPU core does not have direct physical access to the SKU circuitry or to any of the actual encryption key values that are generated by the SKU or used by the EMU. Yet another aspect of the SSEE is that different secure applications can share memory pages using the same key, while using different keys for non-shared memory. This arrangement permits the use of shared, secure libraries, even though each library may maintain its own unique security credentials. A further aspect is that page level encryption may be easily implemented by supplementing operations already existing in the CPU's operating system and memory management unit (MMU) hardware. For example, the operating system may provide on-demand paging where a memory page is mapped in the translation look-aside buffer (TLB) when a virtual page is not already mapped-in. In this example, the operations that load the TLB on-demand are simply extended to also load the page-key mappings in the secure software execution environment architecture at the same time so that no additional event handlers or interrupts are required.
Unlike other security approaches, the disclosed hardware-facilitated secure software execution environment (S SEE) and method provides confidentiality and integrity both program instructions and data without the need for placing trust in any particular software module or significantly altering the execution of the software or the particular operating system that is used.